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ABSTRACT 

This paper presents a library for Supercollider that enables live cod¬ 
ing adapted to two domains of performance: telematic dance with 
wireless sensors and electroacoustic music performance. The library 
solves some fundamental issues of usability in Supercollider which 
have been also addressed by the established live-coding framework 
JITLib, such as modifying synth and pattern processes while they 
are working, linking control and audio i/o between synths, and gen¬ 
eration of GUIs. It offers new implementations, which are more 
compact and easy to use while emphasizing transparency and seal- 
ability of code. It introduces binary operators which when coupled 
to polymorphism facilitate live coding. Several foundation classes 
are introduced whose purpose is to support programming patterns or 
commonly used practices such as the observer pattern, function call¬ 
backs and system-wide object messaging between language, server 
processes and GUI. 

The use of the library is demonstrated in two contexts: a telem¬ 
atic dance project with custom low-cost movement sensors, and dig¬ 
ital implementations of early electroacoustic music scores by J. Har¬ 
vey and K. Stockhausen. The latter involves coding of a complex 
score and generation of a GUI representation with time tracking and 
live control. 

1. BACKGROUND 

1.1. Bridging Live Coding and Gestural Interaction 

The performance practice known as live coding emerged from the 
ability of software to modify state and behavior through the inter¬ 
active evaluation of code fragments and to synthesize audio at run¬ 
time. As a result, several programming environments and technolo¬ 
gies supporting live coding have been developed in the past 20 years, 
such as SuperCollider^ T), Impromptu)!], ChucK 0 , Extempore [ 41 , 
Gibber (5), and others. It has been noted, however, that such envi¬ 
ronments and practices suffer from a lack of immediacy and those 
visible gestural elements that are traditionally associated with live 
performance 0. Recent research projects attempt to re-introduce 
gestural aspects or to otherwise support social and interactive ele¬ 
ments in musical performance using technologies associated with 
live coding ((7J, [ 8 j, | 9|, [10]). Amongst various types of gestural 
interaction, dance is arguably the one least related to textual coding. 
Few recent studies exist which prepare the field for bridging dance 
with coding (fTlj). The challenges in this domain can be summa¬ 
rized as the problem of bridging the symbolic domains of dance and 
music notation and the subsymbolic numerical domain of control 
data streams input from sensors. This also implies translating be¬ 
tween continuous streams of data and individual timed events, pos¬ 
sibly tagged with symbolic values. This is a technologically higly 


demanding task which is subject of research in various gestural in¬ 
terface applications. The work related in the present paper repre¬ 
sents an indirect and bottom-up approach to the topic, based on DIY 
and open source components and emphasizing transparency and self- 
sufficiency at each step. It does not address the task of gesture recog¬ 
nition, but rather it aims at supporting live coding in conjunction with 
dancers and instrumental performers. Ongoing experiments together 
with such performers, are helping to identify low-level tasks and fea¬ 
tures which are essential for practical work. This type of work is 
purely empirical, and tries to identify useability criteria purely from 
practice, rather than to develop features that are inferred from known 
interaction paradigms in other related domains. At this stage of the 
project it is still too early to formulate conclusions from these ex¬ 
periments. Instead, this paper concentrates on the fundamentals of 
the implemenation framework on which this work is based. These 
are readily identifiable and their potential impact on further develop¬ 
ment work as well as experiments are visible. This paper therefore 
describes the basic principles and design strategy of the sc-hacks li¬ 
brary, and discusses its perceived impact on performances. Finally, 
it outlines some future perspectives for work involving data analysis 
and machine learning. 

1.2. Live Coding Frameworks in SuperCollider 

1.2.1. Types of Live Coding Frameworks 

Live Coding libraries can be divided into two main categories de¬ 
pending on the level of generality of their implementation and their 
application scope. First, there are libraries which extend Super- 
Collider usage in order to simplify the coding of very behaviors 
or features which are very common in performance, but are other¬ 
wise inconvenient to code in SuperCollider. To this category be¬ 
longs the JITLib framework. JITLib (Just-In-Time programming Li¬ 
brary) has been around since at least August 2006, with an early 
version since ca 2000 Q and is very widely used in the commu¬ 
nity, being the de-facto go-to tool for live coding in SuperCollider. 
The second category consists of libraries that concentrate on spe¬ 
cialized usage scenarios and attempt to create domain-specific mini¬ 
languages for those scenarios on top of SuperCollider. Such are: 
IXI-Lang (a sequencer / sample playing mini-language by Thor Mag- 
nusson [12]]), SuperSampler (a polyphonic concatenative sampler 
with automatic arrangement of sounds on a 2-dimensional plane, 
by Shu-Cheng Allen Wu [13 ]), and Colliding (An "environment for 
synthesis-oientd live coding", simplifying the coding of Unit Gen¬ 
erator graphs, by Gerard Roma [14]). Finally, TidalCycles by Alex 
McLean fBl should be mentioned, which develops its own live cod¬ 
ing language based on Haskell and focussing on the coding of com- 

1 See https://swiki.hfbk-hamburg.de/ 

MusicTechnology/5 6 6 (accessed 20-December-2018) 
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plex layers of synchronized beat cycles with sample playback and 
synthesis, and uses the SuperCollider synthesis server as audio en¬ 
gine. 

1.2.2. sc-hacks Objectives and Approach 

sc-hacks belongs to the first category of frameworks, and its initial 
motivation was partly to implement some of the solutions of JITLib 
in more robust, simple, and general ways. In parallel, inspiration 
from ChuclC s => operator led to the development of a minimal ex¬ 
tension of the language based on 4 binary operators (+>, <+, * > 
* <), which, coupled with polymorphism, permit simplified and com¬ 
pact coding of several common sound-structure coding patterns. Fur¬ 
thermore, the implementation of some basic programming patterns^] 
opened new possibilities for the creation of GUI elements which up¬ 
date their state. This led to a proliferation of GUI building and man¬ 
agement facilities and resulted in several interfaces for live coding 
tasks, such as a code browser based on the concept of code snippets, 
a browser for editing and controlling the behavior of named players 
holding synth or pattern items, and shortcuts for building GUI wid¬ 
gets displaying values of parameters controlled by OSC, MIDI or al¬ 
gorithmic processes. Finally, ongoing experiments with dancers and 
instrumentalists are giving rise to new interface and notation ideas. 
The current focus is on building tools for recording, visualising and 
playback of data received from wireless sensors via OSC, in order 
to experiment with the data in performance, and to apply machine¬ 
learning algorithms on them. 

2. APPROACH 

2.1. Players and Player Environments 

JITLib addresses four fundamental problems in coding for concur¬ 
rent sound processes: (a) Use of named placeholders for sound gen¬ 
erating processes, (b) managing the control parameters of processes 
in separate namespaces, (c) modifying event-generating algorithmic 
processes (known in SuperCollider as Patterns) on the fly and (d) 
interconnecting audio signals between inputs and outputs of synth 
processes. Sc-lib offers alternative solutions to these problems which 
present advantages, described in the following sections: 

2.1.1. Named placeholders: -def classes vs. Player class 

To use a name as placeholder for a synth process in order to start, 
stop or modify the process on the fly, JITLib introduces the [X-]def 
convention, i.e. it defines a number of classes which act as named 
containers for different types of processes (Synths: Ndef, Tasks: 
Tdef, Patterns Pdef, etc.). Sc-hacks uses a single Player object 
class instead. A Player instance can play a Synth or a Pattern de¬ 
pending on the type of source which it is asked to play, i.e. synth 
definition, synth function, or event-stream generating instance (see 
for example code below[3]). This provides greater flexibility and sim¬ 
plicity in the coding of synth processes over JITLib. 

2.1.2. Separate parameter namespaces: Proxy Space vs. Nevent 

A significant innovation introduced by JITLib consisted in the con¬ 
cept of a ProxySpace, that is, a namespace that can function as the 
current environment. ProxySpace is based on EnvironmentRedirect, 

2 See for example the Observer pattern: https : //en . wikipedia . 
org/wiki/Observer_pattern (accessed 20-December-2018) 


a Class which holds a Dictionary and ensures that a predefined cus¬ 
tom function is executed each time that a value is stored in one of 
the keys of the Dictionary. Sc-hacks defines a subclass of Environ¬ 
mentRedirect similar to ProxySpace, but defines a custom function 
that provides extra flexibility in setting values which is useful during 
performance in accessing control parameters. This enables keeping 
track of which parameter refers to which process, storing parameter 
values between subsequent starts of a process belonging to a player, 
and updating GUI elements to display values as these change. Ad¬ 
ditionally, sc-hacks makes the environment of the player current af¬ 
ter certain operations, in order to make the current context the one 
normally expected by the performer. This however is not always a 
secure solution. For this reason, the target environment can be pro¬ 
vided as adjective argument in binary operators involving players, 
which ensures that code will work as expected even when changing 
the order of execution of code in irregular manner. 

2.1.3. Modifying event generating processes on the fly 

Event generating algorihm processes are implemented in SuperCol¬ 
lider through class Pbind. Pbind takes an array of keys and associ¬ 
ated streams as argument and creates a Routine that calculates pa¬ 
rameters and event types for each set of keys and values obtained 
from their associated streams, and schedules them according to the 
duration obtained from the stream stored under the key dur. The im¬ 
plementation of Pbind allows no access to the values of each event, 
i.e. it is not possible to read or to modify the value of a key at any 
moment. Furthermore, it is not possible to modify the structure of 
the dictionary of keys and streams while its event-generating pro¬ 
cess is playing. This means that Pbind processes cannot be modified 
interactively while they are playing. In order to circumvent this lim¬ 
itation, a number of techniques have been devised which require to 
add code for any key that one wishes to read or to modify. JITLib 
uses such techniques and also provides a way to substitute a Pbind 
process while it is running with a new one, thereby indirectly al¬ 
lowing modification of that process. Sc-hacks provides a new ap¬ 
proach for playing event-generating processes, which uses the same 
Event-playing mechanism as Pbind, but grants both read and write 
access to the data which generate the event stream, and thus permits 
modification of the generating key-stream collection on the fly. This 
radically simplifies the task of modifying event generating processes 
while they are playing. For example, adding or substituting key- 
value stream pairs to a process while it is playing can be achieved 
simply by sending the corresponding key-stream pairs as events to 
the same player, as shown in the following code[T] 

(dur: 0.1) +> \mystream; 

// Substitute duration stream: 

(dur: [0.1, 0.2].prand) +> \mystream; 

// Add degree stream: 

(degree: (-10..10).prand) +> \mystream; 

Figure 1: Adding and substituting key streams to event generators. 

2.1.4. Interconnecting audio signals 

The task of connecting the output of one audio process with the input 
of another audio process is complicated in SuperCollider by the 
requirements (a) to specify the bus which will carry the signal to be 
shared and (b) to ensure that the synth reading from the signal will 
be placed after the bus which is writing to the signal in the execution 
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order of the synth engine (scsynth). The implementation of the 
solution in JITLib involves several classes with several instance vari¬ 
ables and hundreds of lines of code and defies description within the 
scope of the present paper. Additionally, coding the configuration of 
one-to-many or many-to-one interconnections of audio i/o between 
synth processes can be both verbose and complex, as witnessed for 
example in exchanges on the SuperCollider mailing list such as 
this one: https://sc-users.bham.ac.narkive.com/ 
PAapaSaM/many-to-one-audio-routing-in-jitlib 
(accessed 20-December-2018). Sc-hacks introduces a new solu¬ 
tion which permits simpler coding and guarantees persistence of 
established configurations even when the server is rebooted during 
a work session. The implementation is based on mechanisms 
for hierarchical namespaces and function callback implemented 
in sc-hacks through two new classes discussed below: Registry 
and Notification. The coding of one-to-many and many-to-one 
connections is exemplified through the following code [2] 


// many 

\sourcel 

\source2 

// one - 

\source3 

\source3 


■ to - one interconnection 
* > \ f x 1 ; 

*> \fxl; 

to - many interconnection 
*< \fx2; 

*< \fx3; 


Figure 2: Interconnecting audio signals. 

Note that no additional coding is required if using the default input 
and output parameter names \in and \out and number of chan¬ 
nels (1). PersistentBusProxy is used to specify custom parameter 
names and channel numbers. The operator @ can optionally be used 
as shortcut to create PersistentBusProxy instances. 

2.2. Binary operators 

The primary coding strategy of sc-hacks for sound processes is built 
around a small number of binary operators. Each operator encapsu¬ 
lates a group of actions on sound objects such as synthesis parame¬ 
ters, player objects holding single synths or synth processes, busses, 
buffers, midi or osc control instances. The operators are: 


left operand 

operator 

right operand 

source 

+> 

player 

source 

*> 

player 

parameter 

<+ 

value 

parameter 


value 


\default +> \example; // play synthdef 
{ SinOsc.ar(440, 0, 0.1) } +> \example; 

() +> \example; // play event 

(dur: 0.1) +> \example; // modify event 

(degree: [-10, 10, 2].pbrown) +> \example; 

nil +> \example // stop player; 

Figure 3: Player operator +>. 

Additionally, sc-hacks permits one to browse the code executed for 
each player on a dedicated GUI (similar to operations on Shreds in 
the miniAudicle GUI of ChucK ), to edit existing code and resend it 
to the player, and to start or stop a player by clicking on its name in 
the list of existing players, as shown in Figure]?] The list of evaluated 
code strings is permanently saved on file for each session. 



Figure 4: Player GUI. 


2.2.2. *> : Advanced operations on player argument 

The * > operator takes different meanings depending on the type of 
the right operand, as follows: 


type of left operand action 

Event set parameter values without starting events 

Function Play function as routine in environment 

Symbol Add receiver as audio source to argument 

PersistentBusProxy Add source with custom i/o mapping 


2.2.1. +> : Play source in player 

The +> plays the source in the player. The source can be the name 
of a synthesis definition as symbol, a synthesis function, or an event. 
For example the code in [3] can be evaluated line-by-line to play in 
the player named ' example' in sequence a synth using SynthDef 
named 'default' , a Unit Generator Synth Graph containing a 
Sine Oscillator, an empty event with default parameters (degree: 0, 
dur: 1), an event with duration 0.1, and an event with degree a pattern 
using a brownian stream with values between -10 and 10 and max¬ 
imum step 2. Sending different types of sources (synthdef names, 
synth functions, events) to the same player will replace the previous 
source with the newest one. Sending nil stops the player. 


2.2.3. <+ : Set or map parameter 

The <+ operator acts on the parameter named by the receiver (left 
operand) depending on the type of the argument (right operand), as 
follows: 


type of right operand 

action 

Integer or Float 

Set parameter value 

Symbol 

Map parameter to named control bus 

Envelope 

Map parameter to envelope signal 

Function 

Map parameter to Synth Function output 

MIDI 

Bind parameter to MIDI input 

OSC 

Bind parameter to OSC input 
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The parameter named by the left operand belongs by default to the 
current environment. In order to specify a different environment, one 
can name the environment as an adverb to the binary operator using 
standard SuperCollider syntax, e.g.: \freq <+.myenvir 660. 

2.2.4. *<+ : One-to-many audio i/o interconnections 

The *< operator, in analogy to *>, is used to create one-to-many i/o 
interconnections, that is, to connect the audio output from one Player 
to the inputs of several different Players. 

2.3. Fundamental Classes 

To implement the above features, sc-hacks introduces classes which 
implement pattern-language-like features that enable functionality 
across a wide variety of tasks such as storing and retrieving single 
instances in tree data structures (Registry Class), updating state of 
concerned items in response to changes (Notification Class), and en¬ 
forcing sequential order of execution in asynchronous calls to the 
server when booting, loading synthdefs and loading or initializing 
audio buffers (ActionSequence Class). These classes formed the 
backbone for rapid creation of custom extensions to the library to 
meet needs of performance requirements described in the next sec¬ 
tion. These results are encouraging indications that the library will 
serve as framework to develop more ambitious applications in the 
next stages of this work. 


of past code. It is furthermore integrated for use with EMACS as 
primary IDE for SuperCollider, with automatic updates of code be¬ 
tween EMACS and the SuperCollider based GUI. 

Two further features were necessary for the experiments with 
dancers. First, a GUI that displays OSC data as they are received, 
and second a mechanism that scales and assigns incoming OSC data 
to the desired parameters. The following code shows how to generate 
a gui that displays data changes for a set of named parameters. Up¬ 
dates are displayed whenever a parameter is changed, independently 
of the source of the change (i.e. automated algorithm, evaluation of 
code, MIDI or OSC input). 


\lsml.v( 


\dur.slider([0.1, 12], \lsml), 

\pos.slider([0.0, 1.0], \lsml), 

\rate.slider([0.2, 15], \lsml), 
\gps.slider([0.5, 20.0], \lsml), 
\pan.slider([-1, 1.0], \lsml), 
\amp.slider(\amp, \lsml) 


The GUI in figure [6] was generated by the code above. 

Following example shows how to scale data input from OSC mes¬ 
sages and to assign them to named parameters in a specified envi¬ 
ronment ' lsml'. 

\dur <+.lsml 


3. APPLICATIONS 

'/gyroscopel'.osc(0, 
\pos <+.lsml 

[-40, 40], 

[0.01, 12 

3.1. Telematic Dance 

'/gyroscopel'.osc(1, 
\rate <+.lsml 

[-20, 40], 

[0.0, 1.0 

Sc-hacks was first used in a telematic dance project whose goal is 
to enable dancers to perform together concurrently in different cities 

'/gyroscopel' .osc (2, 
\gps <+.lsml 

[-20, 40], 

[0.1, 15] 

by sharing data from motion sensors sent via OSC over the internet 

'/magnetometerl' .osc 

(0, [-1.0, 0 

.5] , 

1161. Sensors were constructed using LSM9D0 motion sensor mod¬ 
ules and Feather Huzzah ESP8266 wifi modules from Adafruit, and 

\pan <+.lsml 

[0.2, 15 

]); 

connected to SuperCollider via micro-osc package on micropython. 

'/magnetometerl' .osc 

(1, [-0.25, 

0.25], 

Several sessions with dancers in Tokyo, Athens and Corfu served 
to experiment with different sound synthesis algorithms and to test 

\amp <+.lsml 

t-l, 1]) 

r 

the usabiity of the interface and algorithms for dance improvisation. 
The results were generally more encouraging than expected, except 
in Corfu where the dancers showed a more cerebral approach em- 

'/magnetometerl'.osc 

(2, [-0.05, 

\amp); 

0.25], 


phasizing control over the sound result rather than free exploration 
of the sonic landscape through movement. 

A significant new turn in the development of the library was 
prompted during the initial tests for remote collaboration performed 
during a workshop organized at the University of Manchester by 
Prof. Ricardo Climent for the EASTN-DC EU-Culture program. 
This showed the need for distributing versions of the library to differ¬ 
ent remote partners, using different custom settings for each partner. 
Opening files in the SuperCollider IDE in order to select and exe¬ 
cute appropriate code segments was soon proven to be impractical 
under the pressed time circumstances of preparing the test within a 
large scale workshop and awkward time-zone difference between the 
partners involved. Thus, a plug-and-play solution had to be devised, 
or at least one that relied on selecting options from menus or lists 
and clicking on buttons rather than opening files and executing code. 
This gave rise to a new interface as a GUI for selecting and evaluating 
snippets of code contained within files within subfolders of a global 
"Snippets" folder [5] The scheme has since served for the archival of 
experiments and performances, facilitating easy overview and reuse 


The above features are only the beginning. As experiments with 
dancers have shown, other GUIs and coding schemes are needed to 
facilitate adjustment of the responsiveness of the sensors and adap¬ 
tation of their sound control aspects during performance. In this re¬ 
spect a considerable amount of work is still required. 

3.2. Coding Electroacoustic Music Performances 

A second test scenario was provided through the collaboration with 
Dan Weinstein, a concert cellist specializing in contemporary music 
performance with good knowledge of contemporary audio tools in 
Linux. Mr. Weinstein selected two pieces from the early repertory 
of electroacoustic music scored for tape recorder: Jonathan Harvey’s 
"Ricercare una melodia" and Karlheinz Stockhausen’s Solo 19. Both 
pieces had to be coded in SuperCollider and rehearsed within one 
week during a residency of Mr. Weinstein in Corfu, leading to a 
public performance of the pieces. The time constraints were critical 
because the pieces were both complex and demanding in terms of 
score interpretation, following and coordination. The Stockhausen 
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• • • 


SnippetList 


— UTILITIES MENU — 


OOOHelpFiles 

OOFirstExamples 

ComputerMusicClass1810 

Delays 

Installations 


MagneticDance 


Performances 
RiaGeorgiadou 
Server 
SoundFiles 
Synth Defs 

TestsAndDevelopment 


MagneticDance180917 

MagneticDance181028 

MagneticDance181028_LH 

MagneticDance_Basic_Recipes 

MagneticDance_Garage21_1_181103 

MagneticDance_Simple_Simulation 

NymphsArtiria181216 


Nymphs_Artiria181215 


UsingBuses 


preload lamentodellaninfa sample 
test buffr 

preload lamentodellaninfa sample 

grain synth 

grain synth gui 

grain synth connection 

simpler sound 

simple gui 

simple controller - twist 
simple controller hand up down vertical 
simple controller up down or twist 
Test with 2 hands 
simple gui 2 hands 


simple controller - twist 


//:preload lamentodellaninfa sample 

\vento.loadBuffer("/Users/iani/Music/sounds/sounds-md/lamentodellaninfa.wav"); 
//:grain synth 
{ 

GrainBuf.ar( 

2, 

Impulse.kr(\gps.kr(1) * 2), 

\dur.kr(1) * 0.5, 
sndbuf: Xlamento.b.bufnum, 
rate: \rate.kr(l) / 2.5, 
pos: \pos.kr(0), 
interp: 2, 
pan: \pan.kr(0) 

) * \amp.kr 
} +> \lsml; 

//:grain synth gui 
\lsml.v( 

\dur.slider([0.1, 12], \lsml), 

\pos.slider([0.0, 1.0], \lsml), 

\rate.slider([0.2, 15], \lsml), 

\gps.slider([0.5, 20.0], \lsml), 

\pan.slider([-1, 1.0], \lsml), 

\amp.slider(\cunp, \lsml) 

); 

//:grain synth connection 

\dur <+.lsml '/gyroscopel'.osc(0, [-40, 40], [0.01, 12.5]); 

\pos <+.lsml '/gyroscopel'.osc(1, [-20, 40], [0.0, 1.0]); 

\rate <+.lsml '/gyroscopel'.osc(2, [-20, 40], [0.1, 15]); 

\gps <+.lsml '/magnetometer1'.osc(0, [-1.0, 0.5], [0.2, 15]); 

\pan <+.lsml '/magnetometer1'.osc(1, [-0.25, 0.25], [-1, 1]); 

\amp <+.lsml '/magnetometer1'.osc(2, [-0.05, 0.25], \amp); 

//:simpler sound 
{ 

SinOsc.ar( 

[Lag.kr(\freq.kr), 

Lag. kr (\ f req2. kr) 

] 

, 0, 0.1) 

> +> \lsml; 

//:simple gui 
\lsml.v( 

\freq.slider(\freq, \lsml), 

\freq2.slider(\freq, \lsml) 

); 

//:simple controller - twist 

\freq <+.lsml '/gyroscopel'.osc(0, [-10, 40], \freq.asSpec); 

/* 

twist of hand 
*/ 

//:simple controller hand up down vertical 

\ f ran 1 } *-4- 1 ami ' / mirno/iAnal 1 nc / 1 r_1f1 Adi \ seCnant . 

\freq <+.lsml '/gyroscopel'.osc(0, [-10, 40], \freq.asSpec); 
\freq2 <+.lsml '/gyroscopel'.osc(1, [-10, 40], \freq.asSpec); 
\freq <+.lsm0 '/gyroscopeO'.osc(0, [-10, 40], \freq.asSpec); 
\freq2 <+.lsm0 '/gyroscopeO'.osc(1, [-10, 40], \freq.asSpec); 

/* 

twist of hand 
*/ 


Figure 5: Snippet List GUI. 


# • • £0 Isml 

dur | I 0.1 

pos | 0 

rate | 0.2 

9PS | 0.5 

pan | 0 

amp | 0 


Figure 6: Grain Control GUI. 


piece proved to be especially difficult as it is initially scored for 4 as¬ 
sistants in the electronic part, where each assistant is assigned control 
of the recording, playback and feedback levels of two tape recording 
channels with varying loop durations between sections, using two 
potentiometers. To execute this with a single performer on the com¬ 
puter, the slider actions as well as the loop duration changes had to 
be automated according to the indications in the score. Even under 
these circumstances, an ideal faithful performance was impossible, 
because each of the 6 levels demanded constant adjustment accord¬ 
ing to the actual level of the instrumental performer, and each transi¬ 


tion had to be timed manually to prevent abrupt noticeable changes. 
Still, this proved to be a fruitful exercise in creating a user inter¬ 
face and coding the entire score, consisting of 6 different realization 
versions. It resulted in a compact coding scheme for durations of 
prescribed length (see[7]for the notation of the first version - Form- 
schema I, and [8] for its translation into GUI and automated perfor¬ 
mance). This notation mechanism can in the future be repurposed as 
a type of beat sequencing notation similar to this found in ixilang or 
TidalCycles (although the Cycle scheme of Tidal has other features 
which go beyond the scope of the present discussion). 

4. CONCLUSIONS AND FUTURE WORK 

Sc-hacks is a general purpose extension to SuperCollider, and the 
intense use of several binary operators may raise doubts about its 
legibility or the general validity of its design priorities. However, 
stress-testing sc-hacks through collaborations with dancers and in¬ 
strumentalists has shown its strong potential to solve diverse and 
demanding problems under time pressure, and furthermore has pro¬ 
vided indications of its scalability in terms of coding various fea¬ 
tures. This indicates that it is a suitable platform for further work, 
and it is hoped that it will serve as a tool for addressing questions 
of machine listening in live performance as well as other advanced 
topics. 
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♦formschemal { 

' v StockhausenSoloFo rmschema ( 

[ // numperiods, duration per period 

[ 11 , 6 ], 

[8, 14.2], 

[7, 19], 

[6, 25.3], 

[9, 10.6], 

[ 10 , 8 ] 

], thisMethod. name.asString 

) 

.loadPeriodStates( 

X_X_XXX_ | XXXXXXX_ | X X | X_X_ | XXX | X_X_X_X_ 
_XX_XX_XXX I XXXXXXX_ I XXX_XXX I XX I XXXXX_XX_ I _x_x_x_x_ 
_XXXX_XXXX I _XXXXXXX I _X_XXX I _X_XX I _XX_XX_ I _xxxxx_x_ 
_x_xx_xx I _XXXXXX_ I _XX_XX I X I _XXXXXXXX I X XX 
_XX_XX_XX_ I _XXX_XXX I XXX_XX_ I _XX_XX I X_XXX_XXX I _x_xx_x_xx 
_XX_XX_X I _X_XXX_X I X XXI _XX_ j XXXI x_xx_x_xxx 

); 

} 


Figure 7: Code for Formschema 1 of Stockhausen Solo 19. 


Recording data received from sensors is a first priority in the project. 
A first prototype has been implemented using the built-in archival 
facilities of SuperCollider. A second implementation is currently 
under development, which will record data into multichannel audio 
signal buffers, and employ an extra channel to record the time inter¬ 
val between receipt of successive OSC messages. Based on this, and 
using the existing graphic visualization facilities of SuperCollider 
for audio signals, a functionality similar to the MuBu tools from IR- 
CAM^jis envisaged. In collaboration with PhD students working on 
Machine Learning, it is planned to use this for further research. 

In parallel, work is being done to connect data sent over the internet 
in remote performances, and in developing a performance repertory 
with instrumental soloists interested in improvisation with live elec¬ 
tronics. In both these cases, the most serious challenge consists in 
making the software stable and easy to use enough to be able to re¬ 
lease it to non-specialist performers for work in real-world creative 
events without the need of specialized technical assistance to run it. 
This remains a major driving factor and design guideline in devel¬ 
oping this software. At the same time it is expected that these re¬ 
quirements will help create best practice solutions that constitute the 
wider contribution of this project. In this sense, the present project is 
placed within the scope of efforts for developing contemporary lan¬ 
guages of notation for performance practice that have lasting impact 
on the community and its aesthetics. 
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Figure 8: GUI for Formschema I of Stockhausen Solo 19. 
























